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Abstract of EP1 054332 

Database (4) comprises objects (5) with standard attributes (6) with the database able to be interrogated 
by an application, user, etc. The objects (5) are characterized by specific attributes (20) with the same 
external structure as standard attributes the internal structure of which enables the administration and 
definition of components (21 ) independent of the database. 
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(54) Systeme et precede de gestion d'attributs dans un environnement oriente objet 



(57) La presente invention conceme un procede de 
gestion d'une base de donnees (4) ou annuaire ou equi- 
valent comportant des objets (5) caracterises par des 
attributs standards (6), la base etant apte a etre interro- 
gee par une application, un utilisateur ou autre, appele 
entite, consistant a caracteriser les objets (5) par des 



attributs specifiques (20) dits attributs opaques (20), 
presentant la meme structure externe que les attributs 
standards (6) et dont la structure interne permet de d6- 
finir et administrer des composants (21 ) de maniere in- 
dependants a !a base (4). 

La presente invention concerne egalement le sys- 
teme mettant en oeuvre ledit proc6de. 
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Description 

[0001] La presente invention concerne le domaine 
des bases de donnees dans un environnement d'ordi- 
nateur oriente objet. 

L'art anterieur 

[0002] Une base de donnees, un annuaire ou equiva- 
lent organise de maniere coherente des objets partages 
par des utilisateurs ou des applications. 
[0003] Un objet est une abstraction d'une donnee du 
monde reel. L'objet est caracterise par une identity un 
etat et un comportement. L'identite d'un objet est repre- 
sents par un identifiant unique et invariant qui permet 
de referencer l'objet independamment des autres ob- 
jets. Les valeurs de I'etat d'un objet sont donnSes par 
des attributs. Le comportement d'un objet est defini par 
un ensemble d'operations applicables a l'objet. Les ob- 
jets similaires sont groupes en classe. Une classe decrit 
la structure et le comportement commun d'objets. Les 
objets et les attributs sont definis dans un schema de la 
base. 

[0004] Dans les bases de donnees actuelles, tous les 
attributs sont declares dans le schema de la base. 
[0005] Or, la complexity et revolution rapide des in- 
formations contenues dans une base de donnees sou- 
levent de nombreux problemes : 
[0006] La description du schema de la base est fre- 
quemment modifiee ce qui necessite une gestion per- 
manente et couteuse de la base et entraine une g§ne 
pour les utilisateurs et administrateurs. 
[0007] Des objets de versions difterentes sont sus- 
ceptibles d'etre geres par une meme base. Le probleme 
de gestion de versions se complique avec la replication 
des bases dans un environnement distribue et plus par- 
ticulierement lorsque les difterentes versions se situent 
sur des machines difterentes. 
[0008] L'utilisateur a souvent besoin d'acceder rapi- 
dement a une suite d'attributs d'un objet donne. La base 
est sollicitee pour la recherche de chacun des attributs. 
II en resulte un encombrement dans la consultation de 
la base, une lenteur dans I'obtention d'une reponse a 
une interrogation. 

[0009] II serait avantageux que des composants de 
types difterents (chaine de caracteres, entier, boo- 
leen...) soient stockes dans un meme attribut, ce qui 
n'est pas realisable avec les systemes actuels connus. 
[0010] L'origine, I'intdgrite ou la confidentiality des in- 
formations stockees dans la base ne sont garanties 
qu'apres application de techniques diverses sur les at- 
tributs, techniques rapportees, lourdes et couteuses. 
[0011] Un but de la presente invention est de permet- 
tre de modifier facilement et rapidement les informations 
associees a une classe d'objets. 
[0012] Un autre but de la presente invention est d'ac- 
ceder rapidement a une suite d'attributs. 
[001 3] Un autre but est d'integrer des composants de 



difterents types dans un mdme attribut. 
[001 4] Un autre but de la presente invention est d'ad- 
ministrer la cohabitation d'objets de versions differences 
dans une meme base ou des bases repltquees. 
5 [001 5] Un autre but est de garantir l'origine, I'integritd 
et la confidentiality de I'intormation sans recours a des 
techniques rapportees. 

Resume de I'invention 

w 

[001 6] Dans ce contexte, la presente invention propo- 
se un procede de gestion d'une base de donnees ou 
annuaire ou equivalent comportant des objets caracte- 
rises par des attributs standards, la base etant apte a 

15 etre interrogee par une application, un utilisateur ou 
autre appele entile, caracterise en ce qu'il consiste a 
caracteriser les objets par des attributs specifiques dits 
attributs opaques, presentant la meme structure exter- 
ne que les attributs standards et dont la structure interne 

20 permet de definir et admin istrer des composants de ma- 
niere independante a la base. 
[001 7] La presente invention concerne le systeme in- 
formatique de mise en oeuvre du procede selon I'inven- 
tion. 

25 [0018] La presente invention se rapporte egalement 
a un systeme informatique comprenant au moins une 
machine munie d'une base de donnees ou annuaire ou 
equivalent susceptible d'etre interrogee par une appli- 
cation, un utilisateur ou autre, appele entite, caracterise 

30 en ce qu'il comprend une interface de programmation 
au niveau applicatrf API entre la base et I'entite compre- 
nant des fonctions d'acces a la base et des fonctions de 
gestion d'attributs standards et/ou d'attributs opaques. 

35 Presentation dee figures 

[0019] D'autres caracteristiques et avantages de I'in- 
vention apparaitront a la lumiere de la description qui 
suit, donnee a titre d'exemple illustratif et non limitatif 
40 de la presente invention, en reference aux dessins an- 
nexes dans lesquels: 

• la figure 1 est une vue schematique du systeme se- 
lon la presente invention ; 

45 • ia figure 2 represente de maniere schematique la 
structure d'un attribut opaque du systeme selon la 
figure 1 ; 

♦ la figure 3 represente de maniere schematique des 
elapes du procede selon la presente invention. 

50 

Description d'une forme de realisation de I'inven- 
tion 

[0020] Comme represente sur la figure 1 , la presente 
55 invention se rapporte a un systeme d'information 1 dont 
I'environnement est de type oriente objet. Le systeme 1 
comporte au moins une machine 2. Le terme « machine 
» est utilise dans un sens general pour designer tout 
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type d'ordinateurs ou Equivalents. 
[0021] Le systeme 1 peut etre un systeme dont I'en- 
vironnement est de type distribue ou local. Dans la for- 
me de realisation illustree sur la figure 1, le systeme 1 
de type distribue comprend trois machines 2a, 2b, 2c, 5 
appelees respectivement machine 2a annuaire, machi- 
ne 2b de stockage, machine 2c d'administration. Seuls 
les composants des machines 2 du systeme 1 caracte- 
ristiques de la presente invention seront decrits, les 
autres composants etant connus de Phomme du metier. 10 
Les machines 2 sont reliees entre elles au travers d'un 
reseau 3 ; dans la forme de realisation de la figure 1 , la 
machine 2a est relive aux machines 2b et 2c par le re- 
seau 3. 

[0022] Le systeme 1 comporte une base de donnees 15 
ou un annuaire 4 ou Equivalent installe sur la machine 
2a annuaire. Dans la description qui suit, il sera fait re- 
ference a I'annuaire 4. L'annuaire 4 contient des objets 
5 caracterises par des attributs de type connu dits attri- 
buts standards 6. Dans Pexemple illustre sur la figure 1 , 20 
les informations sont structures en objets 5 int6gr6s 
dans l'annuaire 4 suivant le modele X500 connu ; la ma- 
chine 2a annuaire communique avec les machines 2b 
de stockage et 2c d'administration au travers d'une in- 
terface 7 LDAR 25 
[0023] Des utilisateurs ou des applications diverses 
ou autres, appeles ci-apres entites 8 sont susceptibles 
d'interroger l'annuaire 4 directement sur la machine 2a 
annuaire I'hebergeant ou a partir d'autres machines 2b, 
2c. Dans I'exemple illustre sur la figure 1, une applica- 30 
tion 8 est instaliee sur la machine 2c d'administration et 
travaille avec les donnees de l'annuaire 4. Selon une 
forme de realisation particuliere, I'application 8 est mu- 
nie d'une interface graphique 9. 

[0024] L'une des machines 2a, 2b ou 2c du systeme 35 
1 (machine 2b de stockage sur la figure 1 ) comprend un 
compilateur 10 de description et des moyens de stoc- 
kage 11 d'au moins un fichier 12 source de description. 
[0025] L'une des machines 2a, 2b ou 2c du systeme 
1 (machine 2c d'administration sur la figure 1 ) comprend *o 
une interface de programmation au niveau applicatif, 
appelee couramment interface AP1 1 3 munie d'au moins 
une fonction 14 de gestion et d'au moins une fonction 
15 d'acces a l'annuaire 4, des moyens 16 de memori- 
sation d'une structure 17 de communication entre Tin- 45 
terface AP1 1 3 et I'entite 8, une memoire tampon 18, un 
module de securite 19. 

[0026] Le precede selon la presente invention consis- 
te a caracteriser les objets 5 par des attributs specifi- 
ques 20 dits attributs opaques 20, presentant la m£me so 
structure exteme que les attributs standards 6 et dont 
la structure interne permet de dEfinir et administrer des 
composants 21 de maniere indEpendante a l'annuaire 4. 
[0027] Les structures des attributs standards 6 sont 
de trois types : de type texte directement lisible par Tin- 55 
terface 7, de type binaire representant une unique infor- 
mation d'un type determine qui n'est pas directement 
lisible par I'interface 7, de type specialise requerant des 



contrdles de syntaxe. 

[0028] Le terme « structure externe » signifie que la 
structure de I'attribut opaque 20 telle que vue par l'an- 
nuaire 4 et I'interface 7 est identique a la structure d'un 
attribut standard 6. Pour l'annuaire 4 et I'interface 7, les 
attributs opaques 20 presentent une structure externe 
de type binaire. Un attribut opaque 20 est consider par 
I'interface 7 entre I'entite 8 et l'annuaire 4 comme un at- 
tribut standard 6. 

[0029] L'attribut opaque 20 est comparable a un 
container : des composants 21 sont introduits dans le 
container. Les composants 21 sont independants de la 
technologie ou de I'organisation de l'annuaire 4. II est 
possible de rajouter des composants 21 dans l'attribut 
opaque 20 sans modifier le schema de l'annuaire 4. Les 
composants 21 introduits dans l'attribut opaque 20 peu- 
vent etre de types varies. 

[0030] L'objet 5 est identifie de maniere unique dans 
l'annuaire 4: les attributs opaques 20 sont crees a cha- 
que besoin specifique d'une entite 8. Le contenu des 
attributs opaques 20 depend de I'entite 8 contrairement 
a celui des attributs standards 6 dependant de l'annuai- 
re 4 et de son schema de base. 
[0031] L'attribut opaque, de type binaire pour I'inter- 
face 7, presente une structure interne determinee sus- 
ceptible d'etre exploitee par I'interface AP1 1 3, structure 
dans laquelle divers types de composants 21 sont clas- 
ses. 

[0032] Selon une forme de realisation de I'invention 
illustree sur la figure 2, la structure interne de I'attribut 
opaque 20 est constitu6e de trois parties : 

• un en-tete 22 ; 

• une table 23 de caracteristiques des composants 
21 ; 

• un ensemble 24 de valeurs des composants 21 . 

[0033] La structure interne de l'attribut opaque est 
predefinie de maniere a retrouver les composants 21 
dans les informations de type binaire de l'attribut opa- 
que 20 comme vu plus haut. 

[0034] L'en-tSte 22fournitdes informations g6nerales 
sur l'attribut opaque 20 concerne telles que : 

• une version du formalisme de la structure utilisee 
pour l'attribut opaque 20 et pour les composants 21 
contenus dans l'attribut opaque 20 concern6. La 
version assure une evolution de la structure de l'ob- 
jet et permet la compatibilite montante et descen- 
dante des structures comme il sera vu plus loin ; 

• une longueur en octets des donnees suivantes de 
I'en-tete (informations de securite, date de derniere 
mise a jour ...) de maniere a retrouver la table 23 
dans les donnees binaires de l'attribut, comme vu 
plus haut ; 

• des informations de securite assurant I'integrite, 
I'origine et la confidentialite des composants conte- 
nus dans l'attribut opaque. Les attributs sont prote- 
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ges d'alterations ou d'extractions non souhaitees. 
Des services de signature et/ou de chiffrement sont 
susceptibles d'etre mis en oeuvre. Les informations 
de securite permettent la signature de i'attribut de 
maniere globale, ce qui ameliore les performances. 
Les informations de securite sont par exemple Pin- 
dication d'une signature souhaitee ou non pour I'at- 
tribut, Indication d'un chiffrement souhaite pour 
tous les composants de I'attribut ou seulement cer- 
tains d'entre eux ou encore non souhaite, la force 
des algorithmes utilises, les algorithmes utilises (si- 
gnature DSA, RSA... ; chiffrement DES, IDEA...), 
I'etat des composants de I'attribut dans I'ensemble 
24 (signe ou non, chrffre ou non), la cle utilisee, la 
valeur de la signature,... 

• une date de derniere mise a jour de I'attribut opaque 
20 concern^ ; ... 

[0035] La table 23 indique les caracteristiques des 
composants 21 contenus dans I'attribut opaque 20 en 
question. Les caracteristiques des composants 21 per- 
mettent notamment de retrouver un composant 21 de- 
termine dans I'ensemble 24 des composants 21 . La ta- 
ble 23 comprend : 

• I'identifiant d'un composant 21 sous la forme par 
exemple d'un num6ro d'identification ; 

• un type de codage du composant 21 concerned Le 
type de codage decrit le mode de representation 
des composants 21 dans I'attribut opaque 20. L'at- 
tribut opaque est susceptible de contenir des com- 
posants de types varies. Le type permet le controle 
du stockage des composants 21 dans I'attribut opa- 
que 20, ('organisation des composants 21 en liste ; 

• des informations complementaires de codage com- 
me par exemple des informations concernant le ty- 
pe multimedia ; 

• une longueur utile de valeur du composant 21 con- 
cerne exprimee en octets ; ... 

[0036] Les composants 21 sont stockes dans I'en- 
semble 24 les uns a la suite des autres dans I'ordre dans 
lequel ils ont ete cites dans la table 23. L'identifiant et 
la longueur utile indiques dans la table 23 permettent 
de retrouver un composant 21 determine dans I'ensem- 
ble 24. 

[0037] L'attribut opaque 20 permet de regrouper des 
composants 21 de types difterents et de permettre 
Tajout, la modification ou la suppression d'un attribut 6, 
20 et/ou d'un composant 21 sans intervenir sur le sche- 
ma de I'annuaire4. 

[0038] Selon une forme de realisation, les types de 
codage determines dans la table 23 se divisent en trois 
categories : les types simples, les types multimedia, les 
types constructeurs. 

[0039] Les types simples comprennent le type texte 
(« TEXT » en annexe) qui correspond a une chaine de 
caracteres (texte quelconque), le type entier de valeur 



binaire, le type numerique (caracteres numeriques de 0 
a 9), le type bit qui correspond a un champ d'octets, le 
type booieen (valeur vrai ou faux), le type 6num6re dont 
la valeur est associee a une constante, le type secret 

5 (texte special de type chiffre et de longueur quelcon- 
que), le type date/heure (format de date/heure etabli). 
[0040] Les types multimedia component le type ima- 
ge, le type son et le type video. 
[0041] Les types constructeurs introduisent et delimi- 

io tent des structures telles que des listes. Le type liste (« 
LIST » en annexe) represente une liste de n occurren- 
ces d'une structure, le nombre maximum d'occurrences 
etant fixe. Le type fin de liste (« END » en annexe) cldt 
la description d'une liste. Les types constructeurs auto- 
risent I'imbrication des listes; n niveaux d'imbrication 
sont possibles. Des regies d'utilisation accompagnent 
les types constructeurs. 

[0042] Tout autre type est susceptible d'etre utilise. 
[0043] Les fonctions 15 d'acces permettent I'acces 

20 aux attributs 6, 20 de I'annuaire 4. Les fonctions 1 5 d'ac- 
ces permettent d'extraire, d'introduire, de modifier ou de 
supprimer des attributs dans I'annuaire 4. Les fonctions 
15 mettent les attributs extraits de I'annuaire 4 a la dis- 
position des fonctions 14 de gestion dans la m6moire 

25 tampon 18. Les fonctions 14 de gestion creent, modi- 
fient, suppriment des attributs et/ou des composants et 
transmettent le resultat des operations aux fonctions 1 5 
d'acc&s par Pintermediaire de la memoire tampon 18 : 
les fonctions 15 d'acces introduisent les attributs et/ou 

30 composants crees ou modifies par les fonctions 1 4 dans 
I'annuaire 4, ou encore suppriment de I'annuaire 4 les 
attributs et/ou composants supprimes par les fonctions 
14 de gestion. 

[0044] Les fonctions 1 4 de gestion sont pr6vues pour 
35 I' exploitation des attributs opaques 20 de maniere inde- 
pendante a I'annuaire 4. 

[0045] Les fonctions 1 4 de gestion permettent d'intro- 
duire ou de supprimer des attributs standards 6 dans 
des objets 5, des composants 21 dans des attributs opa- 

40 ques 20 ou des attributs opaques 20 dans des objets, 
de lire ou modifier des attributs standards 6 ou des com- 
posants 21 des attributs opaques 20, en s'appuyant si 
necessaire sur une description 25 formelle compiiee et 
stock6e dans I'annuaire 4. Les fonctions 14 de gestion 

45 sont susceptibles de lire les composants 21 des attributs 
opaques 20 sans faire appel a la description 25 corres- 
pondante: les fonctions 1 4 de gestion doivent alors con- 
naitre I'identifiant du composant recherche (l'identifiant 
d'un attribut opaque est donne par la table 23 dudit at- 

50 tribut). L'attribut opaque contient le minimum d'informa- 
tions permettant aux fonctions de gestion 14 de lire les 
composants qu'il contient sans informations suppl6- 
mentaires. II est a noter que la lecture est {'operation la 
plus frequente statistiquement. Pour toute autre opera- 

55 tion telle la creation, la modification ou la suppression 
d'un attribut 6, 20 ou d'un composant 21 , la fonction 14 
de gestion requiert les informations de la description 25 
compiiee. Lors d'operations de mise a jour (creation, 
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modification ou suppression), des controles sont neces- 
saires tels que des controles sur les longueurs, les ty- 
pes, les masques, les caracteres obligatoires... : les 
controles s'appuient sur les informations comprises 
dans les descriptions 25 compilees. 
[0046] II est a noter que les informations contenues 
dans les descriptions 25 pourraient, selon une forme de 
realisation de I'invention, etre comprises dans les attri- 
buts opaques 20. Les descriptions 25 compilees ame- 
liorent les performances du systeme 1 . 
[0047] La description 25 de I'attribut opaque 20 est 
issue des fichiers source 12. Un fichier source 12 est 
reserve pour chaque description 25 et pour chaque ver- 
sion de la description 25. La compilation de la descrip- 
tion 25 s'effectue a partir des fichiers source 12 au 
moyen du compilateur 10. La compilation ameliore les 
performances de traitement. 

[0048] La description 25 compilee apporte a I'entite 8 
des informations relatives a un attribut opaque donne 
sans que I'entite ait a soliiciter i'annuaire 4: le fichier 
source 12 contient des informations telles que le libelle 
externe de saisie du champ attribut ou composant « LBL 
» comme il sera vu plus loin, assurant une mise en forme 
automatique des formulaires de saisie de I'interface gra- 
phique 9 de I'entite 8: I'interface 9 est generee automa- 
tiquement sans avoir recours aux attributs stockes dans 
I'annuaire 4. La meme description 25 est utilisee pour 
la saisie de donnees exterieures au systeme 1 et la ges- 
tion de donnees appartenant a I'annuaire 4, ce qui as- 
sure une coherence dans la gestion des informations. 
[0049] Dans la forme de realisation des figures 1 et 3, 
les fichiers source 12 sont enregistres dans la machine 
2b de stockage. Le compilateur 10 de la machine 2b 
transforme le fichier source contenu dans les moyens 
de stockage 11 en une description 25 compilee stockee 
dans I'annuaire 4 de la machine 2a annuaire. La des- 
cription compilee Ii6e a un objet 5 donne est stockee par 
exemple (figure 1) dans un objet 26 special. Le fichier 
compile beneficie des capacites de distribution des 
technologies d'annuaires. 

[0050] La description 25 compile permet une evolu- 
tion en douceur du contenu des objets. Selon un exem- 
ple de forme de realisation, la description 25 comporte, 
comme il sera vu plus loin, le numero de version du con- 
tenu de I'objet 5 concerne : revolution de structure des 
objets 5 est geree a I'aide de numeros croissants de ver- 
sion. 

[0051] La gestion des versions est rendue souple et 
efficace. L'annuaire 4 peut evoluer sans cesse sans re- 
mettre en cause les objets existants et le schema de 
I'annuaire. La gestion des versions est assuree par les 
fonctions 14 de gestion lors de la creation ou suppres- 
sion d'objets 5 dans I'annuaire 4. 
[0052] Selon un exemple de realisation de la gestion 
des versions, il est prevu une compatibility montante en- 
tre ia description 25 d'un objet 5 et I'objet 5 effectif exis- 
tant (objet 5 de version V et description 25 de version 
V+n): 
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[0053] Dans ce cas, afin d'assurer une totale compa- 
tibility c'est a dire une evolution de la structure des ob- 
jets 5 sans remettre en cause les objets existants, les 
regies suivantes sont appliquees dans les fonctions de 
5 gestion 14: 

Si un nouveau composant 21 apparalt dans la des- 
cription 25, il est visible pour I'entite 8 et indique 
comme absent dans I'objet 5 courant mais ajoute 
10 en mise a jour par la fonction de gestion 14 
concemee ; 

- Si un composant 21 disparatt de la description 25, 
il n'est plus visible pour I'entite 8 et est supprime de 
I'objet 5 a la mise a jour par la fonction de gestion 
*5 14 concemee. 

[0054] II est egalement prevu une compatibilite des- 
cendante entre la description d'un objet et I'objet effectif 
existant (objet de version V et description de version V- 
20 n): 

[0055] Cette situation intervient dans des periodes 
transitoires de deploiement d'une nouvelle version de 
description d'objet, et de differences dues a la replica- 
tion des objets. 
25 [0056] Dans ce cas, une compatibilite minimum est 
assuree, permettant un fonctionnement transitoire, en 
attendant la mise a niveau de la description. 
[0057] Les regies suivantes sont appliquees : 

30 - Si un composant 21 est present dans la description 
25 mais ne Test plus dans I'objet 5, le composant 
21 est considere comme absent de la description ; 
Si un composant est absent de la description mais 
present dans I'objet, il est considere comme present 

35 dans la description, accessible dans I'annuaire 4 au 
moyen de I'identifiant mais pas du nom interne qui 
n'est defini que dans la description. 

[0058] Les modifications a apporter au schema de 
40 I'annuaire 4 sont limitees : les evolutions sont deportees 
hors de I'annuaire 4. 

[0059] Dans la forme de realisation de la figure 1 , les 
attributs d'une classe d'objets 5 sont regroupes en 
items. Une classe d'objets peut contenir plusieurs items. 
45 Dans la forme de realisation decrite, un item est cons- 
titue d'au moins un attribut standard 6 et/ou d'un seul 
attribut opaque 20. Un attribut standard 6 ou un compo- 
sant 21 dans un item est appele dans ce qui suit un ele- 
ment de I'item. 

so [0060] D'autres items sont susceptibles d'Stre crees. 
[0061] Les descriptions 25 sont de deux types : 

• les descriptions 25a d'items ; 

• les descriptions 25b d'attributs. 

55 

[0062] L'annexe 1 montre un exemple de description 
25 d'items et d'attributs. 

[0063] La description 25a d'items est referencee sous 
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la forme <Classe> - <ltem>, <Classe> repr6sente la 
classede I'objet 5 concerne, <ltem> I' item concerne (en- 
semble de composants d'un attribut opaque ou ensem- 
ble d'attributs standards dans ladite classe d'objets en 
question). Les items cites sont declares au prealable 
comme appartenant a la classe d'objets correspondante 
dans I'annuaire 4. Un fichier source 12 peut comporter 
une description d'items et une suite de descriptions d'at- 
tributs correspondents. 

[0064] La description 25 d'items comprend les infor- 
mations suivantes : 

• la classe de I'objet concerne, appelee « CLASS ». 
Les classes sont identifies par des mots cles re- 
serves. 

• les items declares dans un objet qui dependent de 
la classe de I'objet en question, appeles « ITEM ». 
Une classe d'objets est constitute de plusieurs 
items. Pour chaque classe, la liste des items qu'il 
doit/peut contenir est definie. A chaque type d'item 
est associe un identifiant unique. Dans la forme de 
realisation decrite, les identifiants sont : 

« BASE »: attributs standards 6 ; 
« XXX » (tout terme different du terme BASE 
utilise pour les attributs standards) : attributs 
opaques 20. 

• la version de la description de I'item, appelee « 
VERSION ». Cette information est tres importante : 
elle assure une evolution compatible de la descrip- 
tion des items. 

• la liste des langues a utiliser, appelee « LANGUA- 
GES » telles que par exemple la iangue utilises 
pour les Nbelles d'attributs, ... ; une description re- 
quiert au moins une Iangue. Si une des langues 
n'est pas fournie explicitement pour un attribut, on 
prend par delaut la premiere Iangue definie dans la 
description pour I'attribut en question. 

[0065] La description 25 d'items peut 6galement corn- 
prendre des informations de stcurite optionnelles. Les 
informations sont dites optionnelles car elles impliquent 
une option par defaut en cas d'absence. Les informa- 
tions de securite sont definies dans I'en-tete 22 de I'at- 
tribut opaque 20 et/ou dans la description 25a d'items 
selon les besoins (options de securite generates et/ou 
pour seulement certains attributs). La protection des at- 
tributs opaques 20 s'effectue par chiffrement et/ou si- 
gnature. Par defaut, par exemple, les attributs opaques 
ne sont ni signes ni chiff res. Les paramdtres optionnels 
de la description 25a autorisent la modification des va- 
leurs de protection par defaut. 
[0066] Selon une forme de realisation, les parametres 
optionnels sont : 



• la signature de I'attribut en question ; 

• le chiffrement de I'attribut concerne ; dans le cas 
d'un chiffrement requis, les composants 21 de type 
secret ne sont pas chiff res individuellement. 

5 • le niveau de chiffrement pour I'attribut en question. 

[0067] La description 25b d'attributs permet : 

• d'identifier chaque element de I'objet concerne par 
10 un nom interne et un identifiant, d'indiquer la cor- 
respondence entre le nom interne et I'identifiant 
pour un element donne ; 

• de definir les types des elements de I'objet 
concerne ; 

75 • de fournir des informations utilisables par les fonc- 
tions de gestion 1 4 des elements 21 ou directement 
par rentrte 8 (interface graphique 9) telles que : 

un libelle(s) du champ de saisie de I'el6ment ; 
20 - une indication du statut obligatoire ou optionnel 
de Tenement ; 

une taille minimum / maximum ; 
des contraintes sur I'element ; 
des informations comptementaires sur rele- 
ts ment. 

[0068] La description comprend : 

• le nom interne de I'element concerne, appele « ATT 
30 »>. Le nom interne permet de nommer simplement 

un element (attribut standard 6 /composant 21 d'un 
attribut opaque 20). II sert de reference pour la ges- 
tion ulterieure des descriptions d'items et pour ('ad- 
ministration de I'annuaire 4. Le nom interne est in- 

35 dependant du nom defini dans le schema de I'an- 
nuaire 4. Le nom interne identifie chaque dtement ; 
il est unique pour un objet 5 donne\ Selon un exem- 
ple illustratif, le nom est donne sur 12 caracteres 
maximum. Le nom doit commencer sur le premier 

to caractere de la ligne ; 

• I'identifiant, appelS I'OID. L'identifiant identifie cha- 
que element ; il est unique pour un item donne. 
L'identifiant est independant de I'identification dans 

45 I'annuaire 4. 

• le nom de l'6lement dans I'annuaire 4 utilise par I'in- 
terface 7 et obligatoire dans la description des at- 
tributs 6 standards, appele « XNM ». II est code par 

50 exemple sur 36 caracteres maximum ; 

• I'indication de retat de I'etement au niveau de I'en- 
tite 8, appele « HID ». L'etat de I'element peut pren- 
dre les valeurs caches ouvisibles. L'HIDest declare 

55 avant les options qui suivent ; 

• le libelle" externe de saisie du champ element tel que 
presents au niveau de I'entite 8, appele « LBL » ; 
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• le type de codage de I'element parmi ceux enonces 
precedemment, appele « TYP ». 

[0069] D'autres options sont susceptibles d'etre utili- 
ses telles que par exemple des options qui sont fonc- 
tion du type de codage de I'element. Quelques exem- 
ples sont donnes ci-apres permettant de comprendre 
I'exemple de fichiers source donne en annexe. 

• I'option « MDT » determine le statut obligatoire ou 
optionnel de I'element ; 

• I'option « RNG » represente la plage de longueur 
(chaine de caracteres, numerique, secret) ou de va- 
leur (entier), ou le nombre d'occurrences minimal et 
maximal (type constructeur). 

• I'option « SZF » definit la taille du champ de saisie 
pour I'interface graphique 9 de I'entite 8. 

• « CAS » definit la casse pour les types chaTnes de 
caracteres ; 

« FREE », la casse est respectee ; 
« UP », les majuscules sont forcees ; 
« LOW », les minuscules sont forcees. 

[0070] Les informations donnees par la description 
telles que I'option SZF par exemple permettent la mise 
en forme automat ique (sans avoir recours a des modu- 
les supplementaires) des formulaires de saisie de I'in- 
terface graphique. 

[0071] Des options sont a prevoir egalement par 
exemple pour les types multimedia tels que : 

• I'option « PLD » indiquant le prechargement auto- 
matique des types multimedias dans la structure. 

• I'option « ALG » qui est un identifiant d'algorithme. 

[0072] Les identifiants d'algorithme pour le type ima- 
ge sont par exemple : 



0 


GIF 


1 


JPG 


2 


TIF (fractales) 


3 


Ondelettes 



Des identifiants sont egalement determines pour les ty- 
pes sons et video. 

[0073] La manipulation des elements s'effectue a 
I'aide des fonctions de gestion 14 en precisant I'item. 
L'item doit etre precise a I'appel afin que les fonctions 
determined la structure concernee par I'operation a ef- 
fect uer. 

[0074] Les fonctions de gestion 1 4 permettent de ma- 
nipuler (creer, lire, modifier, supprimer, afficher) les don- 
n6es suivantes : 



attributs standards des objets de I'annuaire 4 ; 
attributs opaques des objets de I'annuaire 4 et com- 
posants 21 de ces attributs ; 
composants de securite de base integres dans des 
5 attributs des objets 5... 

[0075] Les elements manipules par les entites 8 sont 
contrdles, filtres par les fonctions 14 de gestion. 
[0076] Si la fonction de gestion 1 4 appelee necessite 

10 les descriptions 25a et b compilees de I'objet, lesdites 
descriptions sont chargees automatiquement par la 
fonction de gestion en question. Selon une forme de 
realisation particuliere de realisation, les descriptions 
compilees sont chargees dans la memoire tampon 18. 

J5 Les fonctions de gestion 14 puisent dans les descrip- 
tions compilees les informations necessaires aux ope- 
rations qu'elles doivent effectuer. Les fonctions de ges- 
tion 1 4 s'appuient sur la description 25a d'item pour con- 
naftre la classe d'objet et l'item concernes. 

20 [0077] Les f onct ions de gestion dans la forme de rea- 
lisation decrite sont les suivantes : 

une fonction ^initialisation d'objets InitObj : I'appel 
a cette fonction permet d'initialiser la structure d'un 
25 nouvel objet ainsi que la structure d'attributs 6,20 
de I'objet cree de maniere a pouvoir y inserer des 
attributs standards 6 ou des composants 21 . L'objet 
5 est defini a I'appel de la fonction d'initialisation en 
precisant la classe de I'objet, l'item correspondant. 

30 

une fonction de rangement PutElem : la fonction de 
rangement realise la creation ou mise a jour d'un 
attribut 6,20 ou d'un composant 21 d'un attribut opa- 
que 20. A I'appel de la fonction de rangement sont 

35 precises la version, la classe, I'identifiant ou le nom 
de I'element, I'occurrence en cas de liste, la lon- 
gueur utile dans le cas de types bit ou secret, le type 
de codage de I'element. La fonction de rangement 
actualise pour chaque objet traite une liste des at- 

40 tributs modifiees afin d'optimiser la mise a jour. 

une fonction de lecture GetElem : la fonction de lec- 
ture assure ('extraction d'un attribut 6, 20 ou d'un 
composant 21 d'un attribut opaque 20 de I'annuaire 

45 4. Si le composant demande est recherche par son 
identifiant d'objets, la fonction de lecture n'a pas a 
charger la description compilee : la table 23 inte- 
gree de I'attribut est suffisante. A I'appel de la fonc- 
tion de lecture, sont precises la version, la classe, 

50 I'identifiant ou le nom de I'element, I'occurrence en 
cas de liste, la longueur utile dans le cas de types 
bit ou secret, le type de I'element. 

une fonction de suppression RemElem : la fonction 
55 de suppression effect ue la suppression de la valeur 
d'un attribut 6,20 ou d'un composant 21 d'un attribut 
opaque 20, d'une occurrence d'une liste de compo- 
sants dans un objet. A I'appel de la fonction de sup- 
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pression, sont precises la version, la classe, I'iden- 
tifiant ou le nom de rei6ment, I'occurrence en cas 
de liste, la longueur utile dans le cas de types bit ou 
secret, le type de codage de I'element. 

une fonction de verification CheckObj : la fonction 
de verification verifie les attributs 6,20 d'un objet et 
les composants 21 d'un attribut opaque 20 avant 
validation d'une creation ou d'une modification. La 
fonction de verification permet le contrdle de pre- 
sence obligatoire des attributs/composants. Elle 
peut etre appelee par une entity 8, mais elle peut 
egalement etre mise en oeuvre systematiquement. 
A I'appel de ia fonction de verification, sont precises 
la version, la classe, I'identifiant ou le nom de I'eie- 
ment, I'occurrence en cas de liste, la longueur utile 
dans le cas de types bit ou secret, le type de codage 
de Telement. 

[0078] L'entite 8 appelle une fonction 1 4 de gestion 
en placant les parametres necessaires a ladite fonction 
14 dans la structure de communication 17. La structure 
de communication 17 se presente sous la forme d'une 
succession de tous les parametres necessaires a toutes 
les fonctions 14 de gestion. La fonction 14 de gestion 
appelee recupere dans la structure 17 de communica- 
tion les valeurs de parametres qui I'interessent. 
[0079] Les fonctions 1 4 de gestion renvoient un code 
retour indiquant si la fonction a ete correctement effec- 
tuee, si une erreur est intervenue, si les parametres 
d'appel sont corrects, si la description compile a ete 
retrouvee, si I'objet existe ... 

[0080] Les fonctions 14 de gestion sont concues de 
maniere a suivre les regies de gestion de versions 6non- 
cees plus haut. 

[0081] Les fonctions 1 4 de gestion permettent de lire 
une suite d'attributs/ composants sans solliciter I'an- 
nuaire 4. 

[0082] Les fonctions 1 4 de gestion assurent le chiffre- 
ment/dechiff rement et la signature des composants 21 
contenus dans I'attribut opaque 20. Les fonctions de 
gestion communiquent avec le module de s6curite 19 
pour effectuer les operations de securite (signature, 
chiff rement, .. . ) requises dans une description d'item 25 
et/ou dans I'en-tete 22 d'un attribut opaque. II est a noter 
que le module de securite 19 est independant : I'entite 
8 peut faire appel directement au module de securite 
comme le montre la figure 1. 

[0083] Le systeme 1 decrit fonctionne de la maniere 
suivante : 

[0084] Lorsque I'entite 8 souhaite cr6er un objet dans 
I'annuaire 4, I'entite 8 commence par appeler la fonction 
de gestion 14 d'initialisation : I'entite 8 introduit les pa- 
rametres d'appel suffisants dans la structure de com- 
munication 17. La fonction 14 d'initialisation extrait de 
ladite structure les parametres qui lui sont necessaires, 
charge la description 25 compiiee correspondante dans 
la memoire tampon 18 et cr6e la structure de depart 



d'objet souhaitee en definissant des valeurs par d6faut. 
La structure est enregistree dans la memoire tampon 
18. La structure creee, la fonction 14 d'initialisation in- 
dique a I'entite 8 que la structure est prete a recevoir 

s des attributs standards 6 ou des composants 21 en ren- 
voyant un code retour adapte dans la structure de com- 
munication 1 7. Comme indique plus haut, divers codes 
retour sont susceptibles d'etre transmis a I'entite 8 pour 
lui indiquer I'etat de fonctionnement. Lorsque I'entite de- 
tecte le code retour indiquant que la structure de depart 
a ete creee, I'entite 8 appelle alors la fonction 1 4 de ges- 
tion de rangement: elle transmet a la structure de com- 
munication les caracteristiques des attributs standards 
6 ou des composants 21 qu'elle souhaite introdu ire dans 

*5 I'attribut opaque 20 conceme. La fonction 1 4 de range- 
ment les recupere et remplit la structure d'objets pr6ce- 
demment cr66e dans la memoire tampon 18 en s'ap- 
puyant sur la description compiiee chargee. La fonction 
1 4 de rangement peut egalement faire appel au module 

20 19 de securite en cas de signature ou de chiff rement 
des informations contenues dans I'objet concerne. Lors- 
que I'objet est pret a etre transfere dans I'annuaire 4, 
I'entite 8 a le choix entre valider la creation ou la verifier 
sachant qu'en validant, I'operation de verification est 

25 egalement realisee. La verification avant validation per- 
met d'obtenir precisement toutes les erreurs realisees. 
L'op6ration de verification est effectu6e par la fonction 
de gestion de verification. Lorsque I'entite 8 valide la 
creation, la fonction 15 d'acces transfere I'objet cree et 

30 renseigne dans I'annuaire 4. 

[0085] Lorsque I'entite 8 souhaite modifier un objet 
dans I'annuaire 4, I'entite 8 commence par appeler la 
fonction 15 d'acces. La fonction 15 d'acc&s retrouve 
I'objet dans I'annuaire 4 et en transfere une copie dans 

35 la memoire tampon 18. La fonction 15 d'acces indique 
par code retour a I'entite 8 que I'objet a ete correctement 
transfere dans la memoire tampon 18. L'entite 8 appelle 
alors la fonction 1 4 de gestion de rangement : elle trans- 
met a la structure de communication 17 les caracteris- 

40 tiques modifiees de I'attribut standard 6 ou du compo- 
sant 21 de I'attribut opaque 20 concerne. La fonction 14 
de rangement extrait les parametres qui lui sont neces- 
saires de la structure de communication 17 et charge la 
description compiiee correspondante dans la memoire 

45 tampon 1 8. La fonction 1 4 de rangement modif ie I'objet 
en question enregistre dans la memoire tampon 18 par 
la fonction d'acces 15, comme indique par les parame- 
tres de la structure de communication transmis par I'en- 
tite 8 et conformement a la description compiiee. La 

50 fonction de rangement peut egalement faire appel au 
module de securite 19 en cas de signature ou de chif- 
f rement des informations contenues dans I'objet concer- 
ne. Lorsque I'objet est prdt a etre transfere dans I'an- 
nuaire 4, I'entite 8 a le choix entre valider la creation ou 

55 la verifier sachant qu'en validant, I'operation de verifica- 
tion est egalement realisee. La verification avant valida- 
tion permet d'obtenir precisement toutes les erreurs rea- 
lisees. L'op6 ration de verification est effectu6e par la 
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. fonction de gestion de verification. Lorsque l'entite 8 va- 
lide la modification, la fonction 1 5 d'acces transfere I'ob- 
jet modifie de la memoire tampon 18 dans I'annuaire 4. 
[0086] Lorsque I'entite 8 souhaite supprimer un attri- 
but 6, 20 ou un composant 21 de I'annuaire 4, I'entite 8 
commence par appeler la fonction 15 d'acces. La fonc- 
tion 15 d'acces retrouve I'objet dans I'annuaire 4 et en 
transfere une copie dans la memoire tampon 18. La 
fonction 15 d'acces indique par code retour a I'entite 8 
que I'objet a ete correctement transfere dans la memoire 
tampon 1 8. L'entite 8 appelle alors la fonction 1 4 de ges- 
tion de suppression : elle transmet a la structure de 
communication les caracteristiques de I'attribut stan- 
dard 6 ou du composant 21 a supprimer de I'attribut opa- 
que 20 concerne. La fonction 14 de suppression extrait 
les parametres qui lui sont necessaires de la structure 
de communication 17 et charge la description compilee 
correspondante dans la memoire tampon 18. La fonc- 
tion 14 de suppression supprime le composant 21 ou 
I'attribut 6,20 en question enregistrd dans la memoire 
tampon 18 par la fonction d'acces 15, comme indique 
par les parametres de la structure de communication 
transmis par I'entite 8 et conformement a la description 
compilee. La fonction 15 d'acces supprime I'attribut 6, 
20 ou le composant 21 indique dans la memoire tampon 
18 dans I'annuaire 4. 

[0087] Lorsque I'entite 8 souhaite lire un objet dans 
I'annuaire 4, I'entite 8 commence par appeler la fonction 
15 d'acces. La fonction 15 d'acces retrouve I'objet dans 
I'annuaire 4 et en transfere une copie dans la memoire 
tampon 18. La fonction d'acces indique par code retour 
a I'entite 8 que I'objet a ete correctement transfere dans 
la memoire tampon 1 8. L'entite 8 appelle alors la fonc- 
tion de gestion 14 de lecture. Si les parametres foumis 
par I'entite 8 sont suffisants et en particulier si le nom 
interne de I'attribut standard ou du composant a §te don- 
ne, la fonction de lecture n'a pas besoin de charger la 
description compilee. Dans le cas contraire, la descrip- 
tion compilee est chargee de maniere a obtenir la cor- 
respondence entre le nom interne et I'identifiant. La 
fonction 1 4 de lecture verifie eventuellement si I'entit6 8 
a le droit de lire les informations concernees en faisant 
appel au module de securite 19. Elle dechiffre eventuel- 
lement lesdites informations et v6rifie leur integrite. Elle 
retrouve les informations souhaitees de I'objet en par- 
courant I'ensemble 24 des valeurs a I'aide de I'identifiant 
ou libelle et de la longueur utile. Elle place lesdites in- 
formations dans la structure de communication 17. L'en- 
tite 8 n'a plus qu'a lire les informations requises dans la 
structure de communication 17. 
[0088] Selon un developpement de Tinvention, les 
versions de description anterieures a une version utili- 
see a un instant t sont archivees dans un repertoire 
separe . Les versions de description anterieures peu- 
vent etre archivees par exemple en ajoutant au nom un 
suffixe representant le numero de version. 
[0089] La presente invention concerne done un pro- 
cede de gestion de I'annuaire 4 ou equivalent compor- 



tant les objets 5 caracterises par les attributs standards 
6, I'annuaire 4 6tant apte a etre interroge par l'entite 8, 
caracterise en ce qu'il consiste a caracteriser les objets 
5 par les attributs specifiques 20 dits attributs opaques 
5 20, ptesentant la meme structure exteme que les attri- 
buts standards 6 et dont la structure interne permet de 
definir et administrer les composants 21 de maniere in- 
dependante a I'annuaire 4. 

[0090] Le procede selon Tinvention consiste a definir 
10 et administrer les composants 21 au moyen de I'interfa- 
ce de programmation au niveau applicatif API 13 entre 
I'annuaire 4 et l'entite 8. 

[0091] Le procede consiste a definir la structure inter- 
ne de I'attribut opaque en trois parties : 

75 

I'en-tete 22 delivrant des informations generates sur 
I'attribut opaque 20 ; 

la table 23de caracteristiques des composants 21 ; 
I'ensemble 24 de valeurs des composants 21 indi- 
20 ques dans la table 23. 

[0092] Le procede consiste a integrer dans la struc- 
ture interne de I'attribut opaque 20 des informations de 
securite assurant I'integrite, I'origine et/ou la confidenc- 
es alite des composants 21 contenus dans I'attribut 20. 
[0093] Le procede consiste a integrer dans la struc- 
ture interne de I'attribut opaque 20 des informations per- 
mettant la gestion de differentes versions du contenu de 
I'attribut 20. 

30 [0094] Le procede consiste a integrer dans la struc- 
ture interne de I'attribut opaque 20 le type de codage de 
chaque composant 21 contenu dans ledit attribut 20. 
[0095] Le procede consiste a lire ou mettre a jour, a 
savoir creer, modifier, lire ou supprimer, un attribut stan- 
ds dard 6, un attribut opaque ou un composant 21 dans un 
attribut opaque 20 de maniere independante a I'annuai- 
re 4 au moyen des fonctions de gestion 14 des attributs 
opaques 20 appelees par l'entite 8. 
[0096] Les fonctions 14 de gestion s'appuient sur la 
40 description 25 des attributs 6,20 pour effectuer leur mise 
a jour, ainsi que leur lecture si l'entite 8 n'a pas fourni 
les informations suffisantes pour acceder directement a 
I'attribut concerne dans I'annuaire 4. 
[0097] Le proc6de consiste a compiler la description 
45 25 a I'aide d'un compilateur 10. 

[0098] Le procede consiste a integrer dans la descrip- 
tion 25 des informations de securite assurant I'integrite, 
I'origine et/ou la confidential ite des composants 21 con- 
tenus dans I'attribut 20. 
50 [0099] Le procede consiste, au moyen des fonctions 
1 5 d'acces a I'annuaire 4, a extraire, introduire, modifier 
ou supprimer des attributs 6,20 dans I'annuaire 4 con- 
formement aux operations effectuees par les fonctions 
14 de gestion. 

55 [0100] La presente invention porte egalement sur le 
systeme informatique permettant la mise en oeuvre du- 
dit procede. 

[0101] La presente invention se rapporte a un syste- 
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me informatique comprenant au moins une machine 2 
munie de I'annuaire 4 ou equivalent susceptible d'etre 
interrog6 par Tentite 8, caract6ris6 en ce qu'il comprend 
I'interface de programmation au niveau applicatif AP1 1 3 
entre I'annuaire 4 et Pentite 8 comprenant les fonctions 
15 d'acces & I'annuaire 4 et les fonctions 14 de gestion 
d'attributs standards 6 et/ou d'attributs opaques 20. 
[01 02] L'entite 8 communique avec I'interface AP1 1 3 
au travers de la structure de communication 1 7 enregis- 
tr6e dans les moyens de memorisation 16. 
[0103] Le systeme comprend les moyens 11 de stoc- 
kage des fichiers source 12, le compilateur 10 desdits 
fichiers 12. 

ANNEXES 

Exemples de fichier source 12. 

[0104] / description 25 de I'item BASE de la classe 
d'objets Personne 

CLASS=PERSONNE 
ITEM=BASE 
VERSION=001 
LANGUAGES=EN,FR 

/ description 21 des attributs standards 6 de I'item 
BASE 

ATT=CNAME 
OID=0001 

XNIvbcommonName 
HID=N 

LBL=EN="User common name" 

LBL=FR="ident X500 de I'usager" 

TYP=TEXT 

MDT=Y 

RNG=64 

SZF=24 

CAS=FREE 

ATT=SURNAME 
OID=0002 
XNM=surname 
HID=N 

LBL=EN="User surname" 

LBL=FR="Patronyme X500 de I'usager" 

TYP^TEXT 

MDT=Y 

RNG=32 

SZF=16 

CAS=LOW 

ATT=TELE PHONE 
OID=0003 

XNIVb telephoneNumber 
HID=N 

LBL=EN-"User telephone" 



LBL=FR=Telephone usager" 
MDT=N 
RNG=16 
SZF=16 
5 CAS=UP 

/ description 25 d'un item attribut opaque SECITEM 20 
de la classe d'objets PERSON 
/ description des composants de I'attribut opaque, dans 
10 I'item SECITEM 

CLASS=PERSON 
ITEM=SECITEM 
VERSION=001 
1$ LANGUAGES=EN,FR 

/ description 25 des attributs opaques 20 de I'item 
/ definition de la liste des ressources accordees 

20 ATT=LISTRAL 
OID=100 

LBL=EN="Resource allocated list" 
LBL=FR-"Liste des ressources allouees" 
TYP=LIST 
25 PRS=PCM 
RNG=500 

/ classe des ressources de la liste 

30 ATT=OBJECTCLASS 
OID=101 

LBL-EN="Resource class" 
LBL=FR= n Classe de la ressource" 
TYP=TEXT 
35 RNG=48 
CAS=UP 

/ nom de la ressource 

<Q ATT=OBJECTID 
OID=102 

LBL=EN="Resource name" 
LBL=FR="Nom de la ressouce" 
TYP=TEXT 
45 MDT=N 

SZF=48 

RNG=96 
CAS=UP 

50 / fin description de la liste (d'une occurrence liste) 

ATT=ENDOFLIST 
OID=100 
HID=Y 
55 TYP^END 

/ exemple de description des droits d'accds aux noeuds 
et objets 
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/ droit sur le niveau noeud 

ATT=NODERGT 

OID=102 

HID=N 

LBL=EN-"Rights on node" 

LBL=FR="Droits sur le noeud" 

TYP=TEXT 

MDT-N 

RNG=8 

CAS=UP 

ATT=CHILDGRGT 

OID=103 

HID=N 

LBL=EN="General rights on attached objects" 

LBL=FR='Droits generaux sur les objets ratta- 

chees" 

TYP=TEXT 

MDT=N 

RNG=8 

CAS=UP 

ATT=CLASSRGT 

OID=104 

HID=N 

LBL=EN="Specific rights on attached objects' 

LBL=FR=" Droits specifiques sur les objets ratta- 

chees" 

TYP=TEXT 

MDT=N 

RNG=8 

CAS=UP 



Revendications 

1. Procede de gestion d'une base de donnees (4) ou 
annuaire ou equivalent comportant des objets (5) 
caracterises par des attributs standards (6), la base 
(4) etant apte a etre interrogee par une application, 
un utilisateur ou autre appele entite (8), caracterise 
en ce qu'il consiste a caracteriser les objets (5) par 
des attributs specifiques (20) dits attributs opaques 

(20) , presentant la mSme structure externe que les 
attributs standards (6) et dont la structure interne 
permet de definir et administrer des composants 

(21) de maniere independante a la base (4). 

2. Precede selon la revendication 1 , caracterise en ce 
qu'il consiste a definir et administrer les compo- 
sants (21 ) au moyen d'une interface de program- 
mation au niveau applicatif API (13) entre la base 
(4) et I'entite (8). 

3. Procede selon Tune des revendications 1 ou 2, ca- 
racterise en ce qu'il consiste a definir la structure 
interne de I'attribut opaque en trois parlies : 



un en-tete (22) deiivrant des informations ge- 
nerates sur I'attribut opaque (20); 
une table (23) de caracteristiques des compo- 
sants (21); 

s - un ensemble (24) de valeurs des composants 
(21) indiques dans la table (23). 

4. Procede selon Tune des revendications 1 a 3, ca- 
racterise en ce qu'il consiste a integrer dans la 
10 structure interne de I'attribut opaque (20) des infor- 
mations de securite assurant I'integrite, I'origine et/ 
ou la confidentiality des composants (21) contenus 
dans I'attribut (20). 

15 5. Procede selon I'une des revendications 1 a 4, ca- 
racterise en ce qu'il consiste a integrer dans la 
structure interne de I'attribut opaque (20) des infor- 
mations permettant la gestion de differentes ver- 
sions du contenu de I'attribut (20). 

20 

6. Procedd selon I'une des revendications 1 a 5, ca- 
racteris6 en ce qu'il consiste a integrer dans la 
structure interne de I'attribut opaque (20) le type de 
codage de chaque composant (21) contenu dans 

25 ledit attribut (20). 

7. Procede selon I'une des revendications 1 a 6, ca- 
racterisd en ce qu'il consiste a lire ou mettre a jour, 
a savoir creer, modifier, lire ou supprimer, un attribut 

30 standard (6), un attribut opaque ou un composant 
(21) dans un attribut opaque (20) de maniere ind6- 
pendante a la base (4) au moyen de fonctions de 
gestion (14) des attributs opaques (20) appelees 
par I'entit6 (8). 

35 

8. Procede selon la revendication 7, caracterise en ce 
que les fonctions (1 4) de gestion s'appuient sur une 
description (25) des attributs (6,20) pour effectuer 
leur mise a jour, ainsi que leur lecture si I'entite (8) 

40 n'a pas fourni les informations suffisantes pour ac- 
c6der directement a I'attribut concerne dans la base 
(4). 

9. Procede selon la revendication 8, caracterise en ce 
45 qu'il consiste a compiler la description (25) a I'aide 

d'un compilateur (10). 

10. Procede selon I'une des revendications 8 ou 9, ca- 
racterise en ce qu'il consiste a integrer dans la des- 

50 cription (25) des informations de securite assurant 
I'integrite, I'origine et/ou la confidentiality des com- 
posants (21) contenus dans I'attribut (20). 

11. Procede selon la revendication 7, caracterise en ce 
55 qu'il consiste, au moyen de fonctions (15) d'acces 

a la base (4), a extraire, introduire, modifier ou sup- 
primer des attributs (6,20) dans la base (4) confor- 
mement aux operations effectu6es par les fonctions 
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(14) de gestion. 

12. Systeme informatique comprenant au moins une 
machine (2) munie d'une base de donnees (4) ou 
annuaire ou equivalent susceptible d'etre interro- 5 
gee par une application, un utilisateurou autre, ap- 
pele entile (8), caracterise en ce qu'il comprend une 
interface de prog ram mat ion au niveau applicatif 
API (13) entre la base (4) et I'entite (8) comprenant 
des fonctions ( 1 5) d'acces a la base (4) et des tone- 10 
tions (1 4) de gestion d'attributs standards (6) et/ou 
d'attributs opaques (20). 

13. Systeme selon la revendication 12, caracterise en 

ce que I'entite* (8) communique avec '"interface API '5 
(13) au travers d'une structure de communication 
(17) enregistrSe dans des moyens de memorisation 
(16). 

14. Systeme selon Tune des revendications 12 ou 13. 20 
caract6ris6 en ce qu'il comprend des moyens (11) 

de stockage de fichiers source (12), un compilateur 
(10) desdits fichiers (12). 

1 5. Systeme informatique permettant la mise en oeuvre 25 
du precede selon Tune des revendications 1 a 11. 
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En-tete 

Version ; 

Longueur en octets ; 
• Informations de securite ; 
Date de derniere mise a jour ; ... 



Mis 

Identifiant ; 
Type de codage ; 

Informations complementaires de codage ; 
Longueur utile ; ... 



Ensemble de valeurs 



FIG.2 
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COMPILATION 



DESCRIPTION 
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